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Date: July 18, 2005 

To: Examiner David England 

Art Unit 2143 (Phone Number (571-272-391 2> 

Fax: 703-872-9306 

From: Joseph A. Nguyen, Esq. (Reg. No., 37,899), Attorney for Lam 

Research Corporation (Assignee). 

Re: Application No. 09/539,3 1 3 entitled "Plug And Play Sensor Integration 

For A Process Module" filed March 30, 2000. (Our docket No. 
LAM1P136/P0602) by Huang et ai. 

Total Pages (including this cover sheet): 4 

MESSAGE : 

Dear Examiner England, 

As requested, these are the discussion points I wish to go over during our 
discussion on Tuesday, July 1.9, 2005. Thank you very much for agreeing to discuss the 
case with me. 

I believe, after reading the prior art Kail, Steen and Nakamura multiple times, that 
I have a clear understanding of what they teach and what they are silent on. 
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If you find my interpretation of the prior art Kail, Steen and Nakamura inaccurate, 
I would consider the discussion a success if r could be corrected as to my interpretations 
and have a clearer understanding of your interpretation so I can more productively move 
this case forward. 

I very much look forward to our discussion. 
Best Regards, 
Joseph A. Nguyen, Esq. 



U— Problem Background : Different sensors have different data specifications. 

Besides the fact that different sensors report using different types of data (Boolean vs. 
integers vs. float), the data specifications of different sensors may also specify different 
data ranges (e.g., millivolts versus kilovolts), different data measurement frequencies 
(e.g., milliseconds verus minutes), etc. 
See specification at page 8 lines 14-31. 

2} — . — Problem to be solved: Since the central unit cannot be programmed in advance to 
take into account all sensors existing or sensors to be developed, how can the central unit 
(the "process module computing system 20" in our case) understand what is being sent 
from any generic sensor? 

3) Our approach: Plug-and-play sensor integration (see title). The remote sensor 

automatically informs the central unit of the data specifications so the central unit knows 
what the data specification for the remote sensor is. See specification at page 8, lines. 17- 
29. This way, any generic remote sensor, even off-the-shelf sensor developed after the 
central unit is deployed, can be used in a plug-and-play fashion, and the central unit 
would know the sensors data specification since it is automatically informed before 
hand. 

4) Solution proposed bvKai l (6,225.901 \ Put the responsibility on the remote unit 

to conform to what the central unit needs to understand. Make the remote unit format the 
data before sending to the central unit. In other words, Kail assumes that the remote unit 
has this ability to format, or can be programmed with the ability to format, sensor data so 
the centra! unit can understand. One can only assume that the "formatting*' process at the 
remote unit ensures that the data will be in a format understood by the central unit. All 
Kail said was ''upon receipt, the central monitoring device processes the received 
message and stores the data in a database associated with the sendine portable monitoring 
unit 12" 6 

Note: This is different from our approach, which does not put the responsibility on the 
remote sensor to format the data to conform to the requirements by the central unit. 
Accordingly, our approach does not always require the ability of the remote unit to 
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format data to conform to what the central unit can understand. The problem is that for 
not po^bfe rem ° le * " ° ff - the - Shdf ' Such Proving of the'remote unil is often 

5) Solution proposed hy Sfmi ( 6.ST0 SSQ). Steen is silent with regard to what to do 
if the remote unit commun.cates using a data specification that is different from that used 
h"™' Stee " f suraes that *c central unit ("operating software on the 

system provider s server") can understand the data being received from the CFU 
(Cybersensor field units). 

Although column 3, lines 33-56 seems to broadly talk about updating "sends 
request to update a field parameter or request for up-to-date sensor data", a more in-depth 
reading reveals that Steen suggest that a user can update the CFU (Cybersensor Field 
Unit) via a sen-let (such as the CyberVIP module or more specifically the CyberVIP 
screen). The field parameters of a CFU can be updated by a user via the CyberVIP 

«t ST /t£ "t qU6St t0 " pdatC a fi6ld ° r data P arameter is accomplished by clicking on the 
UPDATE button in the CyberVIP or any software module that allows the parameters to 
be updated." See Steen column 8, lines 12-15). The servlet (e.g., CyberVIP) can also be 
used by the user to obtain up-to-date sensor data from the CFU. 

Note: Steen does not address the problem of data specification mismatch. At best, Steen 
assumes that the user will manually change the field parameter at the CFU if needed. 

Q Solution proposed bv Naka mura (6.233.4Q2) Like Steen, Nakamura is silent 

about the possibility that the sensor units may have different data specifications and how 
to inform the central unit of the data specification of a given sensor unit. Nakamura is 
directed toward averaging control load so as to reduce data traffic congestion improve 
control stability. Nakamura is cited as a secondary reference in paragraph 10 of the 
Office Action to supply the features of "the process module having a process chamber, 
initializing the first sensor, which is able to measure a first parameter in the process 
chamber.") 
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My proposal for amended rlrnm T : We more clearly recite the automatic transmission of 
the reportable spec.fication from the sensor to the central unit. This facilitates the plug- 
rTn^ M integra ; ,0n : We * ,so this transmission on the receipt of the command to get 
reportable spec.ficat.on. We also clearly specify that the reportable specification at least 
specifies the data type of what the sensor intends to send. 

1. (Proposed) A computer implemented method for communicating between a computing 
system of a process module, wherein the process module has a process chamber, and a 
first sensor, comprising the steps of: 

initializing the computing system of the process module; 

initializing the first sensor, which is able to measure a first parameter in the 
process chamber; 

transmitting a connect message from the first sensor to the computing system of 
the process module; 

transmitting a command to get reportable specification, which informs the pioc,^ 
modulo computing ^yotom of th o type of data that will bo provided from tho first Donso r, 
from the computing system of the process module to the first sensor; and 

automatically transmitting, upon receivin f t he command to get reportable 
specification, a reportable specification message from the first sensor to the computing 
system of the process module, the reportable *™c\Gr»,i on being configured to inform th* 
computing system of the processing module at i«,«t th e data type transmitted bv the first 
sensor. 



PACE 4(4 • RCVD AT 7/19/2005 2:02:36 AM (Eastern Daylight Time] * SVR:USPTO-EFXRF-6/0 • DNIS:8729306 * CSID:408-257-S550 • DURATION (mm-ss):02-12 



